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(54) DEVICE, SYSTEM, AND METHOD FOR DISTRIBUTING VIDEO DATA 



(57) In a video data distributing system in which 
video data are transmitted to a video data reproducing 
device from a video data distributing device (5) through 
a network (4) and the reproducing device reproduces 
the received video data, a network load measuring sec- 
tion (18) always monitors the load of the network (4). 
When the load of the network (4) is light the distributing 
device (5) transmits all MPEG data (D1). When the load 
is heavy, the device (5) generates data (D3) of a small 
quantity obtained by thinning out as many frames as 
corresponding to the degree of the load from the MPEG 
data, etc, and transmits the data (D3} to the reproduc- 
ing device. 
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Description 

TECHNICAL FIELD 

5 [0001] The present invention relates to a video data distribution device for distributing video data in response to a 
request, a video data distribution system and a video data distribution method. 

BACKGROUND AITT 

10 [0002] A background art will be described by using Fig. 33. Fig. 33 is a function block diagram showing a system con- 
struction for distributing video data with a high bit rate such as MPEG data and the like from a video server through a 
network to clients. In Fig. 33, numeral 1 denotes a network exclusive for video data distribution, 2 denotes a video 
server connected to the exclusive network 1 for distributing video data, and 3 denotes cfienis connected to the exclusive 
network 1 for receiving and playing back the video data distributed from the video server 2. 

15 [0003] Operation will be described. 

[0004] Upon receiving a data transfer request from the cfient 3. the video server 2 starts flowing the video data 
requested by the exclusive network 1. The client 3 receives and decodes the video data distributed through the exclu- 
sive network 1 to play back videa 

[0005] In the system constituted as shown in Fig. 33. since the network exclusive for video distribution is used as the 
20 network, video playback can be performed sutsstanttally without dropping a frame if the network has a sufficient band 
width. However, the number of the clients 3 and the amount of video data to be distributed are increased, and the result 
is that frame dropping occurs over a long time because the video data cannot be transmitted. 
[0006] Moreover, when the video having a high transfer rate like MPEQ is used on a usual network having an insuffi- 
cient band width except the network exclusive for video distribution, the network load is increased, and statDle video dis- 
25 tribution is not performed. Additionally, other traffics on the network are adversely affected in some case. 

DISCLOSURE OF THE INVENTION 

[0007] The invention has been developed to solve the aforementioned problem, and an object thereof is to provide a 
30 video data distribution device, a video data distribution system and a video data distribution method which alleviate net- 
work loads on video data distribution, stabilize the entire system connected to a neftwork and which can perform a real 
time display with less disturbance at the time of playback. 

[0008] To attain this object, the invention provides a video data distribution device which comprises a load measuring 
unit for measuring the load condition of a network or a video data distribution device, a data extractor tor extracting the 
35 number of frame data conesponding to a measurement result of the load measuring unit from video data including plu- 
ral frame data and a transmitter tor transmitting the frame data extracted by the data extractor. 
[0009] Furthermore, based on the measurement result of the load measuring unit, the data extractor extracts all the 
frame data of the video data when the load is low, and extracts a part of the frame data of the video data when the load 
is high. 

40 [0010] Moreover, by thinning the frame data among plural frame data in the video data, the number of frame data 
based on the measurement result of the load measuring unit is extracted. 

[001 1 ] Additionally, the data extractor extracts the video data with inter-frame compressed frame data deleted there- 
from from the video data having intra-frame compressed frame data and inter-frame compressed frame data based on 
the measurement result of the load measuring unit, and the transmitter transmits the video data extracted by the data 
45 extractor. 

[001 2] Furthermore, the video data is MPEG data. 

[0013] Moreover, the data extractor generates MPEG data with P picture deleted therefrom from MPEQ data having 
I picture and P picture based on the measurement result of the load measuring unit 

[0014] The data extractor also generates MPEG data with B picture deleted therefrom from MPEQ data having I pic- 

so ture and B picture based on the measurement result of the load measuring unit. 

[0015] The data extractor further generates MPEG data with P picture and B picture deleted therefrom from MPEG 
data having I picture. P picture and B picture based on the measurement result of the load measuring unit 
[0016] The data extractor also extracts plural 1 pictures from MPEG data having plural i pictures at intenals corre- 
sponding to the measurement result of the load measuring unit 

55 [001 7] The device of the invention is also provided with an encoder for encoding image signals firom a video camera 
in real time and generating video data having plural frame data and a buffer for temporarily storing the video data gen- 
erated by the encoder. In the data extractor, by thinning frame data among the plural frame data in the video data stored 
in the buffer, the number of firame data based on the measurement result of the load measuring unit is extracted from 
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the video data. 

[0018] The invention further provides a video data distribution device which conprises a load measuring unit for 
measuring the load condition of a video data distribution system, a data extractor for extracting the number of frame 
data corresponding to a measurement result of the load measuring unit from video data including plural frame data and 
5 a transmitter for transmitting the frame data extracted by the data extractor via a networK and a video data playback 
device for receiving the frame data transmitted from the transmitter of the video data distribution device via the networK 
and playing back the received frame data. 

[0019] Furthermore, the load measuring unit measures a load of a processor for controlling operation d the video 
data playback device. 

10 [0020] Moreover, plural video data playback devices are connected to the network, and one frame data transmitted 
from the transmitter of the video data distribution device onto the network is received by each of the plural video data 
playback devices. 

[0021] The video data playback device also transmits a data transfer request in which data amount is designated to 
the video data distribution device plural times, and upon receiving the data transfer request plural times, the video data 
IS distribution device transmits frame data based on the data anxiunt designated by each data transfer request for each 
data transfer request. 

[0022] The video data playback device further transmits a data transfer request in which video data is designated, and 
upon receiving the data transfer request, the video data distribution device transmits plural packets having a part of 
frame data of the video data at predetermined inten/als. 

20 [0023] The invention also provides a video data distribution method which comprises a transmission level determining 
step of determining a transmission level in accordance with a load of the video data distribution system, a data extract- 
ing step of extracting the number of frame data corresponding to the transmission level determined in the transmission 
level determining step from video data including plural frame data and a transmitting step of transmitting the frame data 
extracted in the data extracting step. 

25 [0024] Furthermore, the transmission level determining step is performed in the video data playback device, and is 
provided with a load measuring step of measuring a load of a processor for controlling operation of the video data play- 
back device, a determining step of determining a transnrussion level in accordance with a measurement result of the 
toad measuring step and a transmission level transmitting step of transmitting the transmission level detemnined by the 
determining step from the video data playback device to the video data distribution device. 

30 [0025] Furthermore, a playback step is provided in which the video data playt>ack device receives the frame data 
transmitted by the transmitting step ard plays back the received frame data. 

[0026] Moreover, in the transmission level determining step, when the video data playback device quickly forwards 
and ptays back the video data, the transmission level is determined in such a manner that the video data with a part of 
the frame data thinned from plural frame data included in the video data is extracted. When the quick fon^rardlng play- 
35 back is not performed, the transmission level is determined in such a manner that the frame data of the video data Is 
not thinned. 

[0027] Additionally, in the data extracting step, when the video data playback device quickly fbnwards and plays back 
the video data including plural frame data and voice data, the voice data is deleted from the video data and the number 
of frame data corresponding to the transmission level is extracted to generate video data. In the transmitting step, the 
40 video data generated in the data extracting step is transmitted. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0028] 

45 

Fig. 1 is a system construction view of a client server system according to first, second and fourth embodiments of 
the invention. 

Fig. 2 is a software construction view of an LBR data distribution/playback section according to first, third and fourth 

embodiments of the invention. 
so Fig. 3 is a sequence diagram showing a client initiative type operation of the invention. 

Fig. 4 is a flowchart showing a processing of a client program according to the first embodiment of the invention. 

Fig. 5 is a view showing a data structure of an open request according to the first embodiment of the invention. 

Rg. 6 is a view showing a data structure of a read request according to the first embodiment of the invention. 

Rg. 7 is a flowchart showing a CPU load measurement process according to the first embodiment of the invention. 
55 Fig. 8 is a flowchart showing a network load measurement process according to the first embodiment of the inven- 
tion. 

Fig. 9 is a view showing an offset adjustment process according to the first embodiment of the invention. 

Fig. 10 is a flowchart showing an MPEG data distribution process of a vtieo sender according to the first embodi- 
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ment of the invention. 

Fig. 1 1 is a flowchart showing an LBR processing according to the first enibociinient of the invention. 

Rg. 1 2 is a flowchart showing a picture checking process according to the first emt>odiment of the invention. 

Rg. 13 is a flowchart showing an I picture checking process according to the first embodiment of the inventioa 
5 Rg. 14 is a flowchart showing an IP picture checking process according to the first embodiment of the invention. 

Rg. 15 is a flowchart showing an IPB picture checking process according to the first embodiment of the invention. 

Rg. 16 is a table showing thinning intervals and judgment as to whether or not to fetch a found picture. 

Rg. 1 7 is a view showing a data structure of an MPEG1 system. 

Rg. 18 is a view showing data structure up to a GOP layer of the MPEQ1 system. 
10 Rg. 19 is a sequence diagram of a video distribution process according to the first embodiment of the invention. 

Rg. 20 is a sequence diagram of the video distrilsution process according to the first embodiment of the invention. 

Rg. 21 is a software construction view of an LBR data distribution^layback section according to the second 

embodiment of the invention. 

Rg. 22 is a sequence diagram showing a server initiative type operation of the invention. 
75 Rg. 23 is a flowchart showing a processing of a clierrt program according to the second embodiment of the inven- 
tion. 

Rg. 24 is a flowchart showing a distribution process of a video server according to the second embodiment of the 

invention. 

Rg. 25 is a system construction view of a client server system according to the third embodiment of the invention. 
20 Rg. 26 is a sequence diagram of a video distribution process according to the third emtxxjiment of the invention. 

Rg. 27 is a flowchart showing a proces^ng of a server program according to the third embodiment of the invention. 
Rg. 28 is a ficywchart showing a processing of a client program according to the third ennbodiment of the invention. 
Rg. 29 is a f kswchart showing a processing of a server program according to the fourth ennbodiment of the inven- 
tion. 

25 Rg. 30 is a flowchart showing a processing of a client program according to the fourth embodiment of the invention. 
Rg. 31 is a function block diagram of a video sen/er according to the invention. 
Rg. 32 is a function block diagram showing an I^R processing according to the invention. 
Rg. 33 is a system oonstruction view of a background-art video server. 

30 BEST MODE OF PRACTICING THE INVENTION 

[0029] Rg. 1 illustrates an embodiment of a system construction of a client server system in the present invention. In 
the ent)odiment described below, MPEG data is used as video data. 

[0030] In Rg. 1 , numeral 4 denotes a usual network in which the video data and other data flow. 5 denotes a video 
35 sender for distributing the MPEG data through the network 4 and, for example, a computer witii a known OS mounted 
thereon having a network server function is used. Numeral 6 denotes a disc device for storing the MPEG data, and 7 
denotes a server buffer for reading the MPEG data from the disc device 6. Numeral 8 denotes an LBR buffer used for 
writing LBR data when tiie MPEG data read by the server buffer 7 is converted to LBRed data (hereinafter referred to 
as the LBR data: Low Bit Rate). 9 denotes a client which receives the distributed LBR data to play back tiie LBR data 
40 and. for example, a computer with OS of Microsoft Co having a network function, i.a. Windows 95 mounted thereon is 
used. The client 9 can simultaneously execute application other than videodata playback Numeral 10 denotes a client 
buffer for temporarily storing the MPEG data distributed from the video server 5. 

[0031] Rg. 31 is a function block diagram showing a function of the video server 5. in Fig. 31 , tiie same reference 
numerals as those in Rg. 1 designate tiie same or equivalent sections. Numeral 18 denotes a network load measuring 

45 unit for measuring a load of the network 4. and 1 9 denotes a CPU load measuring unit for measuring a CPU load of the 
video sender 5. A CPU of the video server 5 is a processor for controlling operation of the video server 5. Numeral 91 
denotes a switching unit for selectively outputting MPEG data D1 received from the disc device 6 to a transmitter 92 or 
an LBR processor 12 t)ased on load information measured by the network load measuring unit 18 or the CPU toad 
measuring unit 1 9. Numeral 12 denotes the LBR processor for decreasing data amount of the MPEG data D1 received 

so via ttie switching unit 91 from the disc device 6. Numeral 92 denotes the transmitter for transmitting full data of the 
MPEG data received from the switching unit 91 or the MPEG data (LBR data) having a little data amount received from 
the LBR processor 12 onto ttie network 4. Details of an LBR processing will be described later. 
[0032] Here, the client 9 is a video playback device. The network load measuring unit 18 or tiie CPU load measuring 
unH 1 9 is a load measuring unit. The LBR processor 12 is a data extractor. 

55 [0033] Operation of the video sender 5 will be described based on Rg. 31. 

[0034] The network load measuring unit 18 constantly monitors the load of tiie network 4. The CPU load measuring 
unit 19 also constantiy monitors ttie CPU load. Upon receiving a data transfer request from the client 9, the video server 
5 reads the full data 01 of the MPEG data from the disc device 6. The switching unit 91 receives the full data 01 of the 
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MPEG data, selects the transmitter 92 or the LBR processor 12 based on the load Information received from the net- 
work load measuring unit 18 and the CPU load measuring unit 19, respectively, and outputs the full data D1. Here, the 
lull data means the video data not subjected to the LBR processing. 

[0035] For example, when the load of the network 4 and the CPU load are low, the switching unit 91 selects the trans- 

5 mitter 92 and outputs full data D2. The full data D2 is the same as the full data Dl . 

[0036] On the other hand, when the load of the network 4 and the CPU load are high, the switching unit selects the 
LBR processor 12 and outputs the full data 01 of the MPEG data It is determined based on a predetermined threshold 
whether the load is high/low. The LBR processor 12 havirfg received the full data Dl performs the LBR processing, 
deletes, for example. P picture and B picture from the full data Dl and extracts I picture to generate LBR data D3. 

w thereby decreasing the data amount of the MPEG data. Subsequently, the LBR data D3 having the data amount 
decreased by the LBR processor 12 is outputted to the transmitter 92. Each of the I pictitfe. B picture and P picture indi- 
cates image data of one frame, i.e., frame data. Details of each picture will be described later. 
[0037] Upon receiving the full data D2 or the LBR data D3 from the switching unit 91 or the LBR processor 12, the 
transmitter 92 transmits the received MPEG data D2 and D3 onto the network 4. The MPEG data 02 and D3 transmit- 

IS ted to the network 4 are received by the client 9, and the client 9 plays back the received MPEG data D2 and D3. 
[0038] In the above, the embodiment for deleting the B picture and the P picture has been described but, as shown 
in Fig. 32. the LBR processor 12 can extract the LBR data 03 by deleting the I picture from between the I pictures of 
the full data Dl constituted of plural i pictures. 

[0039] As aforementioned, according to the embodiment of the invention, since the amount of the MPEG data trans- 
20 mitted onto the network 4 is adjusted in accordance with a system load such as the load of the network 4. the CPU load 
and the like, a phenomenon In which video played back by the client 9 is not updated over a long time is inhibited, and 
real-time playback can be performed 

[0040] Furthermore, even in a network in which traffics other than the video data are transmitted/received, the trans- 
mission of the other traffics are prevented from being in a wailing condition over a long time because the network is 
25 occupied by the video data over a long time, and the transmission amount of the vkleo data is decreased in accordance 
with the network load or the like. Therefore, other important traffics can be transmitted. 

FIRST EMBODIMENT 

30 [0041] The video server 5 and the client 9 of a first embodiment according to the invention will be descn*bed in detail. 
The hardware of the entire system is constructed as shown in Rg. 1 . 

[0042] Fig. 2 illustrates a software construction of distribution/playback section of MPEG data and LBR data of the 
video server 5 and the client 9. In Rg. 2. the same reference numerals as those in Rg. 1 designate the same or equiv- 
alent sectiona Numeral 11 denotes a server program for distributing the MPEQ/LBR data, and 12 denotes an LBR 

35 processor for converting the MPEG data into LBR data. Numeral 13 denotes a client program for processing the 
MPEG/LBR data transmitted from the video server 5. 1 4 denotes a known MPEG data playback application, 1 8 denotes 
a network load measuring unit for measuring a load of the network 4, and 19 denotes a CPU load measuring unit for 
measuring a client CPU load. A client CPU is a processor for controlling operation of the client 9. 
[0043] The video data distribution system of the embodiment is operated in a client initiative mode. i.e.. the LBR data 

40 is generated and distributed by the video server 5 in real time in response to a data transfer request from the client 9. 
In the client initiative type, as shown in Rg. 3, in response to the data transfer request from the client 9, the video sender 
5 transfers the requested video data. The client 9 determines a transfer size, offset, transfer mode (MPEG data request 
or LBR data request) and the like in accordance with the load of the network 4, the load of the client 9 itself, LBR or 
special playback request and the like, and requests the video server 5 for the vKleo data. 

45 [0044] Moreover, the client initiative type can be switched to a server initiative type desaibed in a sec(^d embodi- 
ment. 

[0045] The system of the first embodiment is constructed as aforementioned. Operation of LBR data distribulion/jDlay- 
back viftH be described in detail based on a server program shown in Rgs. 10 to 15. processing flowcharts of a client 
program shown in Rgs. 4, 7 and 8 and a protocol between the client and the server shown in Figs. 1 9 and 20. 

so 

1. Operation of Client Program 
1.1 Initialization 

55 [0046] First, at step Si 01 of Fig. 4. immediately after start the client program 1 3 sends a MOUNT request to the server 
program 11 as a server confirmation request (step S241 of Rg. 19). This is performed to confirm whether or not the 
sen/er is started. When no reply is returned from the sender, it is determined that the server is not started, an error mes- 
sage is outputted and the operation is finished. When a reply is returned, the process advances to step Si 03. 
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[00471 Subsequently, the client program 13 measures the network load and the CPU load (steps 8103 and S104). 
The processing is executed as separate processes or separate threads at constant intervals. The processing will be 
described later by using Rgs. 7 and 8. 

[0048] Subsequently, various requests sent from the MPEG data playtjack application 14 are waited for (step Si 05). 
5 [0049] L^on receiving a request from the MPEG data playback application 1 4, the client program 1 3 judges wh^er 
or not the received request is a data transfer request (step SI 06}. When it is the data transfer request, the process 
advances to step 81 10, while when it is not the data transfer request, the process advances to step SI 07. 

1.2 Processing in Response to Requests other than Data Transfer Request 

10 

[0050] In steps S1 07 to Si 09, the request received from the MPEG data playback application 1 4 is transmitted to the 
server (step 8107). the return of a reply is waited for (step Si 08), and the returned reply is transmitted to the MPEG 
data playback application 14 (step S109). After the step S109 is completed, the process returns to the step S105 and 
again waits for a request Here, as one of the requests transmitted at the step 8107. there is an OPEN request (step 
75 8243 of Rg. 1 9). The MPEG data playback application 1 4 transmits the OPEN request for designating a file as an object 
of data transfer before sending the data transfer request. 

[0051] Data structures of the OPEN and READ requests transferred to the server program 1 1 are illustrated in Rgs. 
5 and 6. The OPEN request includes data (thinning interval) indicative of LBR mode designated by the MPEG data play- 
back application 14. i.a. whether the full data or the I^R data Is to be transferred. 

20 

1.3 Processing in Response to Data Transfer Request 

[0052] On the other hand, when the request from the MPEG data playback application 1 4 Is the data transfer request, 
the thinning interval of each picture is determined from the network load and the CPU load obtained at the steps 8103 
25 and 81 04 (step 81 1 0). The step S1 1 0 is a determining step. The thinning interval is a transmission level. Here, to deter- 
mine the thinning interval of each picture is. for example, to select one transmission method from fbllowing transmission 
methods: 

. (1) to transmit data all of IPB: 
30 (2) to transmit data only of IP: 

(3) to transmit data only of I; and 

(4) to transmit data constituted by extracting a part of the data only of I at a predetermined interval. 

The method (1) is selected when the load Is light, (2) is selected when the load is lighter, (3) is selected when the load 
3S is further lighter and (4) is selected when the load is lightest Here, P and B can also be designated in such a manner 
that data is extracted at a predetermined inten/al. Therefore, the thinning interval can be constituted of, for exanple, pic- 
ture designation data indicating which picture is to be extracted and inten^al designation data designating extracting 
inten^al of each pk;ture designated in the picture designation data. It is determined based on a predetermined threshold 
which processing of the above (1) to (4) is to be executed. 
40 [0053] Subsequently, it is judged whether or not there is a change in the thinning interval (Step Si 1 1), and when there 
is a change, the process advances to the next step 8112. When there is no change, the process advances to step 81 14 
to transmit the data transfer request to the vkieo server 5. 

1.4 Change Request Transmission Process 

[0054] When there is a change, the cfient 9 transmits a change request to the video server 5. The change request 
transmitting process is a transmission level transmitting step. The change request includes an identifier indicative of a 
change request order and an identifier indicative of (1} to (4) described in the above step 81 10. 
[0055] Upon receiving the change request, the server program 1 1 rewrites a transfer mode flag stored therein in 
so accordance with the mode designated by the change request, and returns a reply. 

[0056] Upon receiving the reply from the video server 5 (step 81 13), the dient program 13 advances to step 811 4 
and shifts to a processing of tiie data transfer request. 

1.5 Data Transfer Request Processing 

S5 

[0057] The client program 1 3 designates a size requested by the MPEG data playback application 1 4 and transmits 
the data transfer request to the video server 5 (step 81 14. step 8245 of Rg. 19). Subsequently, transmission of data 
from the video server 5 is waited for (step 81 15). Upon receiving the data (step S248 of Rg. 19). the received data is 
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stored in the client buffer 10 (step S1 16), and offset calculation is performed concerning the received data. For the off- 
set calculation, since the data transmftted from the video server 5 is sometimes converted to the LBR data and differs 
from the data size requested at the step S 11 4, the offset is calculated from the total data amount stored In the client 
buffer 10 by repeating the processing of the steps Si 14 to S1 1 7. 
5 [0058] Subsequently, it is judged whether or not the data received from the video server 5 reaches the size requested 
by the MPEG data playback application 1 4 (step 8118). When the size is not reached, the process returns to the step 
Sll4to transmit the data transfer request again. When it is reached, the data stored in the client buffer 10 is transferred 
to the MPEG data playback application 14 (step Si 19). Specifically, judgment Is made based on the offset calculated 
at the step S1 17. 

10 [0059] After the step S1 1 9 ends, the process returns to the step S1 05 to repeat the waiting for the request from the 
MPEG data playback application 1 4 again. The client program 1 3 is operated as aforementioned. 

1.6 CPU Load Measuring Process 

IS [00603 An example of a CPU load measuring process as a load measuring step will be described using Rg. 7. In the 
CPU load measuring process, first the present time (T1) is measured and stored (step S121). Subsequently, low priority 
processing is executed (step S122), and time necessary for the processing, i.a. time (T2) for which the low priority 
processing actually uses CPU is measured and stored (step Si 23). Subsequently, the present time (T3) is measured 
again (step 3124). CPU operation ratio is obtained from the time infamation as follows (step S125): 

20 

CPU Operation Ratio (%)=100-(T2/(T3-T1)x100) 

The higher the CPU operation ratio is. the higher the CPU load becomes, while the lower the CPU operation ratio is, the 
lower the CPU load becomes. 

25 

1.7 Network Load Measuring Process 

[0061] An example of a network load measuring process as a load measuring step will be described using Rg. 8. In 
the network load measuring process, first the present time (T1) is measured and stored (step S131). Suteequently. 
30 data with a constant size (6.g.. 8KB) is sent to an unused port in the video server 5 (step 31 32). and spent time (T2) is 
measured and stored (SI 33). Subsequently, the present time (T3) is measured again (step 31 34). An index for obtain- 
ing a network foad from the time information is obtained as follows (step 31 34): 



35 



Network Load» ((Transferred Data Size)/(T2-T1))/Network Band) 
1.8 Offset Adjusting Process 



[0062] An offset adjusting process will be descrtoed using Rg. 9. AdditionaHy. for the simplicity of description, two LBR 
modes are used: LBR processing Is performed (ON) and LBR processing is not performed (OFF). In case of ON. the 
40 picture designating data and the interval designating data have fixed values. In the example, the processing is started 
in the LBR mode OFF at time TO, the LBR mode ON is used at time T2, and further the LBR mode OFF is used at time 
T5. Additionally, for the simplicity of description the amount of the LBR data is set to half the amount of the original 
MPEG data (full data). 

[0063] Rrst the MPEG data playback appfication 14 issues a data request at time TO, offset 0 and size 10. The 
45 request is passed through the client program 13. the sender program 1 1 and the client program 13, and the data of size 
10 is sent. Subsequently, the MPEG data playback application 14 issues a data request at time T1 , offset 10 and size 
10. The data of size 10 is sent in the same manner as aforementioned. 

[0064] Subsequently, the MPEG data playback application 1 4 requests for the LBR mode ON at time T2 and requests 
for data of offset 20 and size 1 0. The dtent program 1 3 sends an LBR mode ON request to the server program 1 1 . and 
50 requests for data of offset 20 and size 1 0. The server program 1 1 fetches the data of offset 20 and size 1 0, converts the 
data to LBR data of size 5. and sends the data to the client program 13. 

[0065] The client program 13 compares the size of the LBR data sent from the server program 1 1 wrth the size 
requested from the MPEG data playback application 14, and requests the server program 1 1 for data of offset 30 and 
size 10 because the sent data size does not satisfy the request size from the MPEG data playback application 14. In 
55 the same manner as aforementioned, the server program 1 1 sends the LBR data to the client program 1 3. 

[0066] The client program 13 combines the prevfously sent data size and the present sent data size, and compares 
the size wHh the request size from the MPEG data playback applicatfon 14. At this time, since the request size from the 
MPEG data playback appHcation 14 is satisfied, the data sent from the server program 1 1 is sent to the MPEG data 
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playback application 14. 

[0067] The client program 13 stores both the offset and size from the MPEG data playk)ack application 14 and the 
offset and size of an actually used video file, and manages a difference between the request size from the MPEG data 
playback application 14 and the data size sent from the server program 11. 
5 [0068] Subsequently, the MPEG data playback application 14 requests for data at time T3 in the same manner as 
aforementioned. In the same manner as aforementioned, the client program 1 3 requests the server program 1 1 for data 
until the request size from the MPEG data playback application 14 is satisfied. 

[0069] The server program 1 1 sends the LBR data to the client program 13 in the same manner as aforementioned. 
[0070] Subsequently, the MPEG data playback application 14 requests for the LBR mode OFF at time T4. and 
10 requests for data of offset 40 and size 10. The client program 13 sends an LBR mode OFF request to the server pro- 
gram 1 1 while requesting for data of offset 60 and size 10. The server program 1 1 fetches the data of offset SO and size 
1 0. and sends the data to the client program 1 3. 

[0071 ] The MPEG data playback application 1 4 performs playback with the data sent as aforementioned. Additionally, 
when the MPEG data playback application 14 changes a playback positkan. the offset value is initialized by making the 
75 same the offset requested by the MPEG data playback application 14 and the offset of the actually used video file. 

1 .9 Judgment as to Whetiier to Transfer LBR Data or Full Data 

[0072] Here, the MPEG data playback application 1 4 determines with which of the usual data and the LBR data the 
20 playback of the video data is started. When the playback is started with the LBR data, the data can be sent to the client 
program 13. 

[0073] The MPEG data playt)ack application 1 4 can also request for transmission change of the data sent from the 
server program 1 1 from the usual data to the LBR data or from tiie LBR data to the usual data at any time 

25 2. Operation of Server Program 

2.1 Entire Operation of Server Program 

[0074] Operation of the sender program 1 1 will be descrbed based on Rg. 10. The server program 1 1 waits for a 
30 request from the client 9 (step S141 ), and upon rec^ving the request judges whether or not the received request is the 
data transfer request (step SI 42). 

[0075] When the request is not the data transfer request, a processing is performed in response to the request (step 
SI 43), and a processing result is transmitted to the client 9 as a reply (step SI 44). Here, the processing performed at 
the step SI 43 is, for example, opening, closing or another processing of a file of the MPEG data. Moreover, when a 

35 change of the LBR mode is instructed from the client 9. the LBR mode is changed at the step S143. 

[0076] On the other hand, when the request is the data transfer request, the MPEG data is read from the disc device 
6 and the read data is stored in the server buffer 7. At this time, the read MPEG data is MPEG data having a request 
size designated by the client 9 (step 8145). Subsequently, by examining the LBR mode stored inside. It Is judged 
whether or not an LBR processing is necessary (step S146). 

40 [0077] When the LBR processing is unnecessary, the MPEG data stored in the server buffer 7 is transmitted to the 
client 5 (step S149. step S247 of Fig. 19). 

[0078] On the other hand, when the LBR processing is necessary, the LBR processing is performed concerning the 
MPEG data stored in the server buffer 7 in accordance with the LBR mode, and the LBR processed MPEG data is 
stored in the LBR buffer 8 (st^ S147). Subsequently, the MPEG data stored in the LBR buffer 8 is transmitted to the 
45 di^t 9 (step SI 48). The step S148 is a transmitting step. The LBR proces^ng will be described later. 

2.2 LBR Processing 

[0079] The LBR processing as a data extracting step will be described in detail. 
so [0080] In the LBR processing, a predetermined picture is extracted from the MPEG data having I picture. P picture 
and B picture to generate MPEG data having a small data size. 

2.2.1 Data Structure of MPEG1 

55 [0081] Rrst, MPEG1 data structure will be described. Fig. 1 7 shows an MPEG1 system, and Rg. 1 8 shows each con- 
struction of MPEG1 video up to GOP (Group of Pictures) layer. The structure of the MPEG1 data is desaibed in detail 
in document IS0/IEC1 1 1 72-1/2: "Information Technology-Coding of Moving Pictures and Associated Audio for Digital 
Storage Media at up to about 1 .5 Mbit/S". INTERNATIONAL STANDARD. 1 993. 



8 



EP0009012 85 rfile://S:\PATE NT FILESWixs Systems (1459 JGLIWIXS Patents\\/iXS010C\References\EPOQ0901285.cp cl Page 9 of 49 



EP0 901 285 A1 

[0082] In the MPEG1 system MPEG1 video and MPEQ1 audio are synchronized and multiplexed, and the MPEGl 
system is used in case of actual application. As shown in Rg. 17, PACK START CODE. Packet Start code or another 
start code is data of 32 bits, and the data is arranged by byte. Addrtionally. bit patterns of the start codes are not gen- 
erated othenivise in a MPEGl bit stream, and are used for identifying various headers. An information group in which 

5 an outline of the entire stream Is described (e.g., a bit rate or the like) is included in a system header. A time stamp 
(PIS, DTS) or another information is included in other header data An SCR (System Clock Reference) is information 
for setting/calibrating the value of a time reference or SIC (System Time Clock, synchronous signal as a basis) to a 
value intended on the side of an encoder in an MPEG system decoder including video and audio decoders. A GOP cf 
MPEGl video is a random access unit in the MPEG1 video, and the GOP is usually a playback time of about 0.5 sec- 

10 ond. 

[0083] Fig. 18 shows a content in detail when the packet data of Rg. 17 is video data, and I. P and B in a GOP layer 
denote I picture, P picture and B pknure, respectively. The content of each picture is as follows: 

I picture: Intra-Pteture (intra-f rame encoded image) 
IS The I picture is an encoded image plane only from the information In'espective of pictures belbre and after the I pic- 
ture, and generated without using an inter-frame prediction. The I picture is a sort of intra-f rame compressed frame 
data. 

P picture: Predictive-Picture (inter-frame fonward-direction predictive encoded image) 

The P fMCture is an image plane formed by performing prediction from I or P picture. Specifically, the picture is rep- 
20 resented by a difference from the previous I or P picture. The P picture is a sort of inter-frame compressed frame 
data. 

B Picture: Bidirectionally predictive* Rcture (Bidirectionally predictive encoded image) 

The B picture is an image plane fbnned through bi-directional prediction being an MPEG characteristic. Specifi- 
cally, the picture is represented by a difference from the I or P picture before or after the B picture. The B picture is 
25 a sort of inter-frame compressed frame data. 

2.2.2 Description of Operation of LBR Processing 

[0084] Details of an LBR processing performed by the LBR processor 12 will be described based on Fig. 12. 
30 [OQSSi Rrst, the LBR processor 12 judges whether a pack header position of the MPEG data stored in the server 
buffer 7 has been defined (step 81 51). and when it has been defined, the process advances to step Si 59. When it has 
not been defined, the process advances to step S1 52 to define the pack header position. 

[0086] In the defining of the pack header position, first the content of the MPEG data stored in the server buffer 7 is 
examined sequentially from the top ol the data, pack header data is searched for (step Si 52). and the found pack 

35 header is copied to the LBR buffer 8 (step 81 53). 

[0087] Subsequently, it is checked whether the data following the pack header is a system header (step 81 54). When 
it is the system header, the system header portion is copied from the server buffer 7 to the LBR buffer 8 (step SI 55). 
When it is not the system header, the processing of the step SI 55 is skipped and the process advances to step S156. 
[0088] After the step SI 54 or Si 55 ends, it is checked whether the subsequent data in the server buffer 7 is a video 

40 packet (step SI 56). When it is the video packet, picture checking of step Si 57 is performed. Through the picture check- 
ing, a predetermined picture is extracted into the LBR kxjffer 8. The picture checking will be described in detail using 
Fig. 12. On the other hand, when it is not the video packet, the process goes to step S1 58, and the data to the end of 
the packet is copied from the server buffer 7 to the LBR buffer 8. There is an audio packet as a packet except the video 
packet, and the audio packet is copied to the LBR buffer 8. 

45 [0089] Subsequently, it is checked whether the next data is a pack header (step SI 59). When it is the pack header, 
the pack header is copied from the server buffer 7 to the LBR buffer 8. When it is not the pack header, the process 
advances to step 8161. 

[0090] After the step S159 or 8160 ends, it is checked whether the next data is a system header (step 8161). When 
it is the system header, the system header is copied from the server buffer 7 to the LBR buffer 8 (step SI 62). When it 

so is not the system header, the process advances to step SI 63. 

[0091] After the step 8161 or 8162 ends, it is checked whether the subsequent data is a video packet (step 8163). 
When it is the video packet, picture checking is performed (step 8165). The picture checking is the same as the 
processing of the above step S157. On the other hand, when it is not the video packet, the data to the end of the packet 
is copied from the server buffer 7 to the LBR buffer 8 (step Si 64). 

55 [0092] After the step SI 64 or 81 65 ends, it is checked to the end of the MPEG data in the server buffer 7 whether the 
above processing is completed (step 8166). When the processing is not completed to the end of the MPEG data in the 
sen/er buffer 7. the process advances to step 81 59, and the processing of steps S159 to 8165 is repeated. 
[0093] On the other hand, when the processing is completed to the end of the MPEQ data in the server buffer 7. the 
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LBR header is written to the top of the LBR buffer 8. the top of the packet (step Si 67). The LBR header is a header 
for distinguishing the MPEG data from the LBR data. At this time, if the packet size is changed when the I. P or B picture 
is fetched (at S1 55 or 81 65 of picture checking), the length of the packet in the packet header is changed based on the 
length of the packet written to the LBR buffer After the step S167 ends, the LBR processing (step S147) is completed 
5 (step SI 68). 

[0094] The LBR processing is performed as aforementioned. 

2.2.3 Picture Checking 

10 [0095] The picture checking described in the above steps SI 57 and S165 will be described in detail using Rgs. 12 to 
15. 

[0096] Fig. 1 2 shows three types of picture checking, and details of the picture checking will be described with refer- 
ence to Figs. 13 to 15. 

[0097] First, it is judged whether or not the 1, P and B pictures are fetched based on the thinning interval notified on 
75 the side of the server at the above step S1 12 of Fig. 4 or when the MPEQ data is opened (step S171). When It is judged 

that the pictures are fetched, the picture checking is completed after IPS picture checking is performed (step 81 72). 

When it is judged that the pictures are not fetched, it is judged whether the I and P pictures are fetched (step Si 73). 

When rt is judged that the pictures are fetched, the picture checking is completed after IP picture checking is performed 

(step 81 74). When it is judged that the pictures are not fetched, it is judged whether the I picture is fetched (step 81 75). 
20 When it is judged that the picture is fetched, the picture checking is completed after I picture checking is performed (step 

SI 76). When it is judged that the picture is not fetched, the picture checking is completed. 

I Picture Checking (Step 3176) 

25 [0098] In the I picture checking, a pan or the whole of the I picture is extracted from the MPEG data, and data with P 
picture and B picture deleted therefrom is generated. 
[0099] Details will be descrft)ed using Fig. 13. 

[0100] Rrst, pts. dts and an I picture flag are checked (step S181). The t picture flag is a flag indicating whether or 
not the data pointed by a pointer at present is in I picture data, the data is in the I picture when the flag is ON. and the 
30 data is not in the I picture when the flag is OFF. The pointer herein is a known file pointer and used for having access 
to the MPEG data stored in the server buffer 7. 

[01 01 ] Subsequently, it is judged whether the position pointed by the pointer at present in the data of the server buffer 
7 is in the 1 picture, i.a . whether or not the I picture flag is ON (step S1 82). When it is in the I picture, the data from the 
position pointed by the pointer to the end of the packet is copied from the server buffer 7 to the LBR buffer 8 (step 8190), 
35 and the I picture checking (step Si 76) is completed (step 8191). 

[0102] On the other hand» when the position is not in the I picture, the top of the I picture is retrieved from the position 
pointed by the pointer at present toward the end of the packet (s^ 3183). When the top of the I picture is not found, 
the I picture checking is completed (step SI 91). 

[0103] When the top of the I picture is found, it is judged based on the thinning interval whether the found picture is 
40 fetched (step 81 84). The thinning interval is an interval notified by the client 9. For example, judgment is made as shown 
in Rg. 16. Rg. 16 illustrates an example of a table showing judgment of the step S184 and the fike for the interval des- 
ignating data of the thinning interval. In a case where the interval designating data of the designated thinning interval is 
"2", when the step 8184 is executed for the first time, it is judged to be Yes, the process advances to step Sl85, and the 
picture is fetched. When the process passes step 8189 and the like and returns to the step 8184. i.e., when the step s 
45 executed for the second time, it is judged to be No, the process advances to the step S189, and no pk;ture is fetched. 
Thereafter, in the same manner, it is judged to be Yes for the third time, and No for the fourth time. In another thinning 
inten/al. judgment is made in the same manner as shown In Rg. 1 6. 

[0104] When it is judged at the step S184 that the I picture is fetched. i.e.. when it is judged to be Yes, the process 

advances to the step Si 85 to turn on the 1 picture flag. 
so [0105] Subsequently, the end of the I picture is retrieved from the pointer position toward the end of the packet (step 

8186). When there is no end to the terminal end of the packet it is judged that all the data is of the I picture, the data 

from the pointer position before the retrieval of the step SI 86 to the terminal end of the packet is copied from the server 

buffer 7 to the LBR buffer 8 (step S187), and the I picture checking (step 3176) is completed (step S191). 

[0108] On the other hand, when the end of the t picture is found at the step S186, the picture flag turned on at the 
55 step S185 Is turned off. and the data from the pointer position before the retrieval of the step 8186 to the found end of 

the I picture is copied from the sen/er Ijuffer 7 to the LBR buffer 8 (step 8188).. 

[0107] Subsequently, it is checked to the end of the packet whether the checking is completed (step S189). When the 
checking is completed to the end, the I picture checking (step SI 76) is completed (step 31 91). When the cheddng to 
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the end of the packet is not completed, the process returns to the step Si 83. and the above processing is repeated 
(step SI 89). 

[0108] Additionaliy, in the aforementioned processing, when the data is copied from the server buffer 7 to the LBR 
buffer 8. the pointer pointing the packet data in the sen/er buffer 7 is advanced by the copied data. Moreover, when 
5 retrieval is performed, the pointer also moves to the retrieved position, 

IP Picture Cheddng 

[0109] In the IP picture checking, a part or the whole of the I and P pictures is extracted from the MPEG data, and 
10 data with B picture deleted therefrom is generated. 

[0110] Details will be described using Fig. 1 4. The IP picture checking is basically the same as the I picture checking 
(step 8176) shown in Rg. 13 except in that the data to be extracted are I and P pctures. 

[0111] Rrst, pts. dts, an I picture flag and a P picture flag are checked (step S201). The P picture flag is a flag indi- 
cating whether or not the data pointed by a pointer at present is in P picture data, the data is in the P picture when the 

75 f laig is ON. and the data is not in the P picture when the flag is OFF. 

[01 1 2] Suk>sequently. it is judged whether or not the position pointed by the pointer at present in the data of the server 
buffer 7 is in the I or P picture, i.e. , whether or not the I or P picture flag is ON (step S202). When the position is in the 
I or P picture, the data from the position pointed by the pointer to the end of the packet is copied from the server buffer 
7 to the LBR buffer 8 (step S210). and the IP picture checking (step 8174) is completed (step 821 1). 

20 [0113] On the other hand, when the position is not in the I or P pknure. the top of the 1 or P picture is retrieved from 
the present position toward tiie end of the packet (step 8203). When the top of tiie I or P picture is not found, the IP 
picture checking is completed (step S21 1). 

[01 1 4] When the top of the I or P picture is found, it is judged based on the thinning inten/al whether the found picture 
is fetched (step S204). The thinning Interval is an interval notified by the client 3 concerning each of the I picture and 
25 the P picture. For example, judgment is made as shown in Rg. 16. When the top of the I picture is found at the step 
S203. the judgment shown in Rg. 16 is made with the thinning interval designated for the I picture. On the other hand, 
when the top of the P picture is found at the step S203. ttie judgment shown in Rg. 1 6 is made with the thinning interval 
designated for the P pictura 

[0115] When it is judged at the step SS04 that the picture is fetched, i.e.. when it is judged to be Yes. the process 
30 advances to the step S205 to turn on the I picture flag or the P picture flag in accordance with the picture top found at 
the step 8203. 

[01 1 6] Subsequently, tiie end of the I or P picture is retrieved from the pointer position toward the end of the packet 
(step S206). When there is no end to the terminal end of the packet, it is judged that all the data Is I or P picture, the 
data from the pointer position before the retrieval of the step 8206 to the terminal end of the packet is copied from the 
55 server buffer 7 to the LBR buffer 8 (step 8207), and the IP picture checking (step 8174) is completed (step S211). 
[0117] On the other hand, when the end of the 1 or P picture is found at the step 8206. tiie picture flag turned on at 
the step 8205 is turned off. and tiie data from the pointer position before the retrieval of the step 8206 to the found end 
of the I or P picture is copied from the server buffer 7 to the LBR buffer 8 (step 8208). 

[01 18] Subsequently, it is checked to the end of tiie packet whether tiie checking is completed (step 8209). When the 
40 checking is completed to the end. the IP picture checking (step Si 74) is completed (step S21 1). When the checking to 
the end of the packet is not completed yet, tiie process returns to the step 8203, and tiie above processing is repeated 
(step 8209). 

[0119] Additionally, in tiie aforementioned processing, when the data is copied from tiie server buffer 7 to tiie LBR 
buffer 8. tiie pointer pointing the packet data in the server buffer 7 is advanced by tiie copied data. Moreover, when 
45 retrieval is performed, the pointer also moves to the retrieved position. 

IPB Picture Checking 

[0120] In the IPB picture checking, a part or the whole of the I. P and B pictures is exf acted from the MPEG data to 

so generate data. 

[01 21 ] Details will be described using Rg. 1 5. The iPB picture checking is basically the same as the I picture checking 
(step 81 76) shown in Fig. 13 except in ttiat tiie data to be extracted are I. P and B pictures. 
[0122] Rrst, pts. dts, an I picture flag, a P picture flag and a B picture flag are checked (step 8221). The B picture flag 
is a flag indicating whether or not tiie data pointed by a pointer at present is in B picture data, the data is in the B pk:ture 
ss when the flag is ON. and it is not in the B picture when the flag is OFF. 

[01 231 Subsequently, it is judged whether or not the position pointed by the pointer at present in the data of the server 
buffer 7 is in the I. P or B picture, i.e.. whetiier or not tiie I, P or B picture flag is ON (step 8222). When tiie position is 
in the i. P or B picture, the data from the position pointed by tiie pointer to the end of the packet is copied from ttie server 
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buffer 7 to the LBR buffer 8 (step S230). and the IPB feature checking (step SI 72) is completed (step S231). 
[0124] On the other hand, when the position is not in the I. P or B picture, the top of the I, P or B picture is retrieved 
from the present position toward the end of the packet {step S223). When the top of the I, P or B picture is not found, 
the IPB picture checking is completed (step S231). 

5 [0125] When the top of the L P or B picture is found, it is judged based on the thinning interval whether the found 
picture is fetched (step S224). The thinning interval is an interval notified by the client 3 concerning each of the I, P and 
B pictures. For example, judgment is made as shown in Rg. 16. When the top of the I picture is found at the step S223. 
the judgment shown in Fig. 16 is made with the thinning intervcti designated for the I picture. On the other hand, when 
the top of the P picture is found at the step S223, the judgment shown in Fig. 16 is made with the thinning inten/al des- 

10 ignated for the P picture. When the top of the B picture is found, the judgment shown in Fig. 1 6 Is made with the thinning 
interval designated tor the B picture. 

[0126] When it is Judged at the step S224 that the picture is fetched, i.e.. when it is judged to be Yes. the process 
advances to the step S225 to tum on the I, P or B picture flag in accordance with the picture top found at the step S223. 
[01 27] Subsequently, the end of the I, P or B picture is retrieved from the pointer position toward the end of the packet 

75 (step 8226). When there is no end to the terminal end of the packet, it is judged that all the data is I, P or B picture, the 
data from the pointer position before the retrieval of the step S226 to the terminal end of the packet is copied from the 
sender buffer 7 to the LBR buffer 8 (step 3227), and the IPB picture checking (step S172) is completed (step S231). 
[0128] On the other hand, when the end of the I, P or B pfoture is found at the step 8226, the pkiture flag turned on 
at the step S225 is turned off, and the data from the pointer position before the retrieval of the step S226 to the found 

20 end of the I. P or B picture is copied from the server buffer 7 to the LBR buffer 8 (step S228). 

[0129] Subsequently, it is checked to the end of the packet whether the checking is completed (step 8229). When the 
checking is completed to the end, the IPB picture checking (step SI 72) is completed (step S231). When the checking 
to the end of the packet is not completed yet, the process returns to the step S223. and the above processing is 
repeated (step S229). 

25 [0130] Additionally, in the aforementioned processing, when the data Is copied from the sen/er buffer 7 to the LBR 
buffer 8, the pointer pointing the packet data in the server buffer 7 is advanced by the copied data. Moreover, when 
retrieval is performed, the pointer also moves to the retrieved position. 

[0131] According to the first embodiment, as shown in Fig. 20. since transmissfon/receipt of high<juality full data 
(steps 8271 to 8273) and transmission/receipt of LBR data with less data amount (steps S274 to 8277) are switched 
30 in accordance with the load condition of the network 4 or the CPU. the MPEG data can be distributed in real time even 
in a strict load oondltfon. 

[0132] Especially, since the frame data is transmitted at the predetermined inten/al by thinning the MPEG data, a phe- 
nomenon is inhibited in whfoh the full data in a certain time is generated in a concentrated manner, the network load is 
so high that the video data cannot be transmitted, the transmission of the MPEG data is behind video playback time 

35 and, consequently, the MPEG data in another time cannot be played back. 

[0133] Moreover, in a case where the load of the client 9 is so high that a sufficient CPU time cannot be allotted for 
video playbacK frame dropping occurs even if the full data is transmitted. According to the embodiment, since the CPU 
foad of the video playback device is measured to perform the LBR processing in accordance with the CPU load, in the 
above case the LBR data having the data amount decreased is transmitted, and the network load can be alleviated. 

40 [0134] In the first embodiment, the MPEG data has been described as the video data, but even another video data 
can have the data amount to be transmitted adjusted by appropriately thinning the inter-frame compressed frames or 
the intra-frame compressed frames and the inter-frame compressed frames to perform the LBR processing as long as 
the data has the intra-frame compressed frames and the inter-frame compressed frames. 

[0135] The intra-frame compressed frame data herein is frame data compressed based on the data in the frame itself, 
45 and the inter-frame compressed frame data is frame data compressed based on a difference from another frame. 

SECOND EMBODIMENT 

[0136] Fig. 1 shows a system construction in a second embodiment of the invention. Fig. 21 shows the MPEG data 
so of the video server 5 and the client 9, and SN construction of the distribution/j3layback section of the LBR data In Rg. 
21 . the same reference numerals as in Fig. 2 designate the same or equivalent sections, and the network load meas- 
uring unit 18 and the CPU load measuring unit 19 are not in the client program 13 but in the server program 11. 
[0137] The second embodiment is a system operated in a server initiative type. In the server initiative type, the full 
data or the LBR data is generated and distributed in real time by the video server 5 in response to the data transfer 
55 request from the client 9. As shown In Rg. 22, the data transfer request from the client 9 is used as a trigger to start 
distribution. Subsequently, the video server 5 takes the information from the network load measuring unit 18 and the 
CPU toad measuring unit 19 into consideration, and the appropriate amount of data continues to be distributed to the 
client on the side of the vWeo sender 5. The cfient 9 receives and plays back the sent data. Additionally, the server initi- 
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ative type can be switched to the client initiative type halfway. 

(0138] The system of the second embodiment is constructed as aforementioned. The distrilxition/playback of the full 
data or the LBR data will be described in detail based on processing flowcharts of Rgs. 24 and 23 of a server program 
and a client program. Additionally, in Rg. 23 the same reference numerals as those in Rg. 4 designate the same or 
5 equivalent sections, and in Rg. 24 the same reference numerals as those in Rg. 10 designate the same or equivalent 
sections. 

10139] In the processing flowcharts of Rgs. 23 and 24. first the MPEG data playback application 14 transmits the data 
transfer request (step S1 14 of Fig. 23). The request is transferred from the cfient program 13 via the network 4 to the 
server program 11, 

10 [0140] The server program 11 activates the network load measuring unit 18 and the CPU load measuring unit 19 in 
independent processes when the program is started, and constantly measures the network load and the CPU load. 
[0141 ] Upon receiving an LBR start request (steps 8141 and SI 42 of Rg. 24). the sen/er program 1 1 reads the MPEG 
data from the disc device 6 to the server buffer 7 to generate the LBR data (step SI 45). 

[0142] Subsequently, the server program 11 determines the LBR mode based on the network load and the CPU load 
IS measured by the network load measuring unit 18 and the CPU load measuring unit 19. The determining method is the 
same as the method described in the first embodiment 

[0143] Subsequently, it is judged based on a determination resuH of step 8300 whether the LBR processing is per- 
formed (step S146). and the LBR processing is performed at step Si 47 when it is judged to be performed. The LBR 
processing is performed in the same method as in the first embodiment 
20 [0144] Subsequently, the sender program 1 1 distributes the full data or the LBR data generated by the LBR buffer 8 
to the client program 13 (step SI 48 or S149). 

[0145] Subsequently, it is judged whether transmission is completed to the terminal end of the file (EOF) of the MPEG 
data designated from the client 9 by the data transfer request (step S301). When the transmission is completed, the 
process returns to the step SI 41 and waits for the next request from the client 9. When the transmission to the terminal 

25 end of the file is not completed, the process returns to the step S145 to transmit the next MPEG data. 

[0146] By repeating the afaementioned, the server program 1 1 of the second embodiment continues to distribute the 
LBR data. On the other hand, the client program 13 receives the sent LBR data (step Si 15 of Rg. 23), stores the data 
in the client buffer 10 (step Si 16). and transfers the full data or the LBR having the size requested by the MPEG data 
playback appfication 14 to the MPEG data playback application (step S1 19). The MPEG data playback applk;ation 14 

30 plays back the data. 

[0147] By repeating the aforementioned, the MPEG data is played back. 

[0148] Since the amount of the MPEG data to be transferred is autornatically adjusted in accordance wrth the network 
and CPU load conditions before distributton also in the second embodiment, the video data can be played back in real 
time. 

35 [0149] Additionally, in the second embocfiment. the MPEG data has been described as the vMeo data, but even 
another video data can have the data amount to be transfen'ed adjusted by appropriately thinning the inter-frame com- 
pressed frames or the intra-frame compressed frames and the inter-frame compressed frames to perform the LBR 
processing as long as the data has the intra-frame compressed frames and the inter-frame compressed frames. 

40 THIRD EMBODIMENT 

[0150] Fig. 25 shows a system construction in a third emhodiment of the invention. 

[01 51] In Fig. 25, the same reference numerals as those in Fig. 1 show the same or equivalent sections. Numeral 15 
denotes a video camera, 16 denotes a real-time encoder for receiving a video signal from the video camera 15 to 
45 encode the signal into the MPEG data in real time, and 17 denotes a real-time data buffer for storing the MPEG data 
encoded by the real-time encoder. 

[0152] Moreover, as not shown, the video server 5 has a parameter memory buffer for storing various parameters of 
the MPEG data used for playing back the MPEG data during multi-casting, for example, a frame rate and the like. 
[0153] Rg. 2 shows a S/W construction of an LBR data distribution/playback section of the video server 5 and the 

50 client 9 in the embodiment 

[0154] In the embodiment the LBR data generated by subjecting the MPEG data encoded in real time to the.LBR 
processing on the video server 5 in real time or the LBR data generated from the usual MPEQ data stored in the disc 
devfee 6 of the first embodiment is distributed to the clients 9 in a multi-cast mode (hereinafter referred to as the multi- 
cast LBR distribution). Here, in the third embodiment the client initiative type operation is performed in the same manner 

55 as in the first embodiment Additionally, the client initiative type can be switched to the server initiative type described 
tn the second embodiment 

[01 55] The system of the third embodiment is constructed as aforementioned, and details will be described based on 
a sequence diagram of Rg. 26 and processing flowcharts of Rgs. 27 and 28 of a server program and a client program. 
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In Fig. 27 the same reference numerals as those in Rg. 10 designate the same or equivalent sections, and in Fig. 28 
the same reference numerals as those in Rg. 4 designate the same or equivalent sections. Rg. 26 is the sequence dia- 
gram showing the distribution by the multi-cast mode for transfening data, and shews that the video server 5 simulta- 
neously transfers data to two clients 9. 

5 [0156] Rrst, operation on the side of the cHent 9 will be described. The MPEG data playback application 14 desig- 
nates the multi-cast mode and sends an OPEN rec^est. Upon receiving the OPEN request, the client program 1 3 trans- 
mits a multi-cast group participation request via the network 4 to the video server 5 (step SI 07 of Fig. 28, step S320 of 
Rg. 26). The multi-cast group participation request is a request having a role of the OPEN request in the first embocfi- 
ment and a role of requesting for participation into the multi-cast group. 

10 [0157] Subsequently, the diem program 13 performs the processing of steps S108 to 8 11 3, and transmits a data 
transfer request or a real-time data transfer request based on an instruction of the MPEG data playback application 14 
(step 81 14 of Fig. 28. step S321 of Rg. 26). 

[0158] Subsequently, the client program operates in the same manner as in the first embodiment to play back the 
MPEQ data transmitted from the video server 5. 

IS [0159] Operation on the side of the video server 5 will be described using Fig. 27. 

[0160] Upon receiving the request from the client 9 ai the step S141, the server program 11 judges whether the 
received request is the data transfer request or the real-time data transfer request (step 831 0). 
[01 61 1 When it is not the data transfer request or the real-time data transfer request, it is judged whether or not the 
received request is a multi-cast group participation request (step S31 1 of Fig. 27). When it is the multi-cast group par- 

20 ticipation request, the server program 1 1 registers the client 9 having transmitted the multi-cast group participation 
request into the multi-cast group (step 8312), and returns a reply including ID infornnat'on of the registered multi-cast 
group (step S144). When it is not the multi-cast group participation request, the process advances to step SI 43, and 
the processing as described in the first enl^odiment is performed. 

[0162] On the other hand, when It is judged at the step S3 10 that the received request Is the data transfer request or 
25 the real-time data transfer request. It is judged whether the received request is a first real-time data transfer request 
(step S313). When it is the first real-time data transfer request, a start request Is oulputted to the real-time encoder 16 
(step 8314). Upon receiving the start request, the real-time encoder 16 starts encoding a video signal received from the 
video camera 15. Specifically, the real-time encoder 16 receives video being photographed by the video camera 15, 
encodes the MPEG data in real time, and simultaneously writes the MPEG data onto the disc device 6 and the real-time 
30 data buffer 7. Here the multi-casting using the MPEG data written on the disc device 6 can also be realized. The real- 
time encoder 1 6 continues to perform the real-time encoding aftenwards until a stop request is sent from the server pro- 
gram 1 1 . 

[0163] Immediately after sending the real-time encoding start request, the server program 1 1 stores the MPEG data 
sent from the real-time encoder 16 in the parameter memory buffer. The buffer Is used for storing various MPEG data 
35 parameters, e.g.. the frame rate and the like in such a manner that the client connected during the multi-cast distribution 
can generate the MPEG data from halfway. 

[0164] Subsequently, the MPEG data is read in the server buffer 7 (step S315). When the MPEG data is read, the 
source from which tiie MPEG data is read differs depending on the data transfer request or the real-time data transfer 
request, and in case of the data transfer request the MPEG data is read from the disc device 6 as described in the step 
40 SI 45 of Fig. 1 0. In case of the real-time data transfer request, the MPEG data is read from the real-time data buffer 1 7. 
The reading of the MPEG data from the real-time data buffer 1 7 Is the same as tine processing In the step 81 45 of Fig. 
10 except in that tine reading source is different. 

[0165] Subsequently, the processing of steps SI 46 to Si 49 is performed in tiie same manner as in the first embodi- 
ment, and the MPEG data is distributed to the client 9. The MPEG data is distributed in the multi-cast mode to all tiie 
45 clients 9 registered in the multi-cast group at the step 831 1 . Specifically, by designating ID of the multi-cast group in an 
output destination of data transfer packet, the packet is transmitted. Each client having received the reply transmitted at 
the step 81 44 determines whether or not the ID of its multi-cast group designated by tiie reply and the ID transmitted 
onto the network 4 coincide with each other, and receives the packet In case of colncidenca 

[0166] By performing the above processing, plural clients 9 can simultaneously receive the distribution of video data. 
so In tills case, since tiie video data can be supplied to plural clients 9 in one transmission, the network load is effectively 
reduced. 

[0167] Rg. 26 is a sequence diagram showing the distribution of video data by multi-casting. 
[01 es] Rrst. one of the clients 9 or client A transmits a multi-cast group participation request (step S320). Upon receiv- 
ing the group participation request, tiie video server 5 registers the client A into the multi-cast group as aforementioned. 
55 Subsequentiy. the client A outputs the data transfer request (step S321). and receives the video data from tiie video 
server 5 (step S322). At this time ance a client B does not participate in the multi-cast group yet, the client cannot 
receive the data. Additionally, tiie data transfer request is outputted herein, txjt the real-time data transfer request is sim- 
ilarly transmitted. Subsequentiy. when the data transfer request is sent from the MP^ data playtsack application 14 
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and there is a sufficient empty capacity in the client buffer 10. the data transfer request is oulputted again (step S323), 
10169] Suk>sequentiy, when one of the clients 9 or cJient B transmits the multi-cast group participation request (step 
S327). the video server 5 registers the dient B in the multi-cast group, and returns a reply having ID infbrmation of the 
multi-cast group. 

5 [0170] Thereafter, the data transfer request is outputled from the client A or B (step S330 or the like), the video server 
5 distributes the video data in response to the data transfer request (step S329 or the like) and the processing is 
repeated. Here the distributed video data is received by the clients A and B, and the clients A and B play back the video 
data. The MPEG data playback application 1 4 or the client program 1 3 does not output the data transfer request when 
the predetermined amount of the MPEG data remains in the client buffer 10. Therefore, it is determined dependent on 

w the amount of the MPEG data stored in the client buffer 10 which of the clients 9 transmits the data transfer request, 
and the dient 9 whose data amount first reaches the predetermined amount or less transmits the data transfer request. 
[01 71 1 Additionally, in the third embodiment, the MPEG data has been described as the video data, but even another 
vkleo data can have the data amount to be transferred adjusted by appropriately thinning the inter-frame compressed 
frames or the intra-frame compressed frarfies and the Inter-frame compressed frames to perform the LBR processing 

15 as long as the data has the Intra-frame conpressed frames and the inter-frame compressed frames. 

FOURTH EMBODIMENT 

[0172] Fig. 1 shows a system construction in a fourth embodiment of the invention. The system construction is the 
20 same as in the first embodiment, but the LBR buffer 8 is used as a quick forwarding buffer. Fig, 2 shows a S/W construc- 
tion o1 a quick fonwarding data distrftxjtion/jalayback section of the video server 5 and the client 9. the S/W construction 
is the same as in the first embodiment, but the LBR processor 12 is used as a quick fonYarding processor. 
[0173] The fourth embodiment operates in the dient initiative mode in the same manner as the first embodiment. 
Moreover, the quick forwarding data of the fourth embodiment is the same as the LBR data of the first embodiment in 
25 that the I picture is fetched, and different from the LBR data in that the audio packet is deleted and the values of PTS 
and DTS in the packet are changed for quick fonwarding playback 

[0174] The system of the fourth embodiment is constructed as aforementioned. Quick fonwarding distribution will be 
desCTibed in detail based on processing f towcharts of Figs. 29 and 30 of the server program 1 1 and the client program 

30 [D17g Fig. 29 is a flowchart showing quick fon*warding data distribution process of the video server 5, and in Fig. 29 
the same reference numerals as those in Fig. 10 designate the same or equivalent sections. 

[0176] Rg. 30 is a flowchart showing processing of the client program 13. and in Fig. 30 the same reference numerals 
as those in Fig. 4 designate the same or equivalent sections. 

[0177] In the processing flowcharts of Figs. 29 and 30. first the MPEG data playback application 14 sends a quick 

35 forwarding request. The quick fonwarding request is sent by transmitting a packet which includes an Identifier indicative 
of the quick fonwarding request and data specifying the video data. The quick fonfvarding request may be sent even dur- 
ing playback or stoppage of video. The request is received by the client program 13 (step S101). and the client program 
13 transmits the request to the video server 5 (step S350). The operation of the video server 5 will be described later 
[0178] When the quick fbnvarding data is sent from the video server 5 (step S115). the data is stored in the client 

40 buffer 10 (step S1 16). offset is calculated (step S11 7) and the processing of the steps S350 to S1 1 7 is repeated until 
the data having a size requested by the client buffer 10 is stored (st^ S1 18). When the data with the size requested by 
the client buffer 10 is stored, the quick fbnwarding data is transfen-ed to the MPEG data playback application 14 (step 
Si 19). The quick fonwarding data is MPEG data. Subsequently, the same data transfer process is repeated between 
the client program 1 3 and the server program 1 1 . 

45 [01 79] In the data transfer process, first the quick tbnwarding request from the M PEG data playback application 1 4 is 
waited for (step Si 01). the quick IbnwarcBng data is transferred to the MPEG data playback application 14 when the data 
of the size requested by the client buffer 10 is stored (step Si 19), and the offset is calculated (step S1 17). The data 
transmitted at the step Si 1 9 in the data transferring is the same as the quick forwarding data already transmitted to the 
MPEG data playback application 14. 

50 [0180] When the clienit program 13 transfers the quick fonwarding data stored in the client buffer 10 to the playback 
application 1 4, the quick fonvarding data (for one image plane) may be transferred once (usually) or the same data may 
be transferred plural times. By transferring the data plural times, the quick fbnwaiding playback speed can be changed. 
For example, when the same data is continuously transferrekJ twice, the playback speed becomes 1/2 of the speed 
when the data is transfen-ed only once. Naturally the data flowing in the network also becomes 1/2. The quick fdnward- 

5s ing data transferred In this manner is played back by the playt)ack application 14. 
[0181] Operation of the server program 1 1 will be described. 

[0182] The server program 1 1 having received the quick fbnwarding request at the step S341 reads the MPEG data 
from the disc device 6 into the sen/er buffer 7 to generate the quick fbnwaiding data (step Si 45). Subsequently, the 
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MPEG data is subjected to the LBR processing, and the quick forwarding data is generated in the same method as in 
the first emtxxiiment (step Si 47). However, the following procedure is different from the LBR data generating method 
of the first embodiment. 

5 •Fetching Packet other than Video Packet 

[0183] When the packet Is other than the video packet, the packet is not written onto the quick fbnwarding buffer 8. 
•Changing Packet 

10 

[0184] The values of PTS and DTS in the packet are changed for quick fonvarding playback 
[0185] Subsequently; the server program 1 1 distributes the quick fonwarding data generated in the quick fonvarding 
buffer 8 to the client 9 (step S148). By repeating the aforementioned in the server program 1 1 , the quick forwarding data 
is distributed. 

75 [0186] Especially, when the video data is displayed by the client in a quick forwarding mode, display is not degraded 
even if the frames to be transmitted are thinned instead of transmitting all the frame data of the video data. Specifically, 
in a case where 30 frames per second are played back at the tme of usual playback, when double-speed playback is 
performed, 80 frames per second are played back according to simple calculation. IHowever. e/en when the data of 30 
frames per second or the data of 60 frames per second is displayed, no difference in picture quality is recognized 

20 because of human visual characteristics. For example, in the double-speed playback 30 frames per second may be dis- 
played. Therefore. In this case, among plural frame data in the video data, every other frame data may be ^acted and 
transmitted as shown in Fig. 32. At this time, since the data anKunt transmitted by the video server is reduced, the load 
placed on the network can be alleviated. Quick fonwarding may be requested by designating a transmission level in 
accordance with quick forwarding speed such as double speed and five times the speed. 

'25 [0187] By repeating the aforementioned, the quick forwarding data is distributed/played back. 

[0188] Additionally, in the fourth emt>odiment the MPEG data has been described as the video data, but the invention 
can be easily applied to the video data having frames compressed through inter-frame compression. 
[0189] As aforementioned, the vkJeo data distribution device of tiie invention is provided witii the load measuring unit 
for measuring the toad condition of the network or tiie video data distribution device, the data extractor for extracting the 

30 number of frame data corresponding to the measurement result of the load measuring unit from the video data including 
plural frame data and the transmitter for transmitting the frame data extracted by the data extractor. Therefore, the dis- 
play quality of tine video data is prevented from being deteriorated, while the network load can be alleviated. 
[0190] Furthemx)r6, based on the measurement result of the load measuring unit, the data extractor extracts all tiie 
frame data of the video data when the load is low. and extracts a pan of the frame data of the video data when the load 

3s is high. Therefore, the display quality of the vkJeo data is prevented from being deteriorated, while the network load can 
be alleviated. 

[0191] Moreover, by thinning the frame data among plural frame data in the vkleo data, tiie number of frame data 
based on the measurement result of the load measuring unit is extracted. Therefore, the display quality of tiie video 
data is prevented from being deteriorated, while the network load can be alleviated. 
40 [01 92] Additionally, the data extractor extracts the video data with inter -frame compressed frame data deleted there- 
from from the video data having intra-lrame compressed frame data and inter-frame compressed frame data based on 
the measurement result of the load measuring unit, and the transmitter transmits the video data extracted by the data 
extractor. Therefore, the display quality of tiie video data is prevented from being deteriorated, while the network load 
can be alleviated. 

4s [0193] Furthermore, since the video data is MPEG data, MPEG data able to be played back in real time can be pro- 
vided. 

[0194] Moreover, since tiie data extractor generates MPEG data with P picture deleted tiierefrom from MPEG data 
having I picture and P picture tDased on the measurement result of the load measuring unit the video data with less 
image disturt>ance can he provided even if the video data amount is reduced. 
so [0195] Since the data extractor also generates MPEG data with B picture deleted therefrom from MPEG data having 
I picture and 6 picture based on the measurement result of the load measuring unit, the MPEG data able to be played 
back in reeti time can be provided. 

[0196] Since the data extractor furtfier generates MPEG data with P picture and B picture deleted therefrom from 
MPEG data having I picture, P picture and B picture based on the measurement result of the load measuring unit, the 
55 MPEG data able to be played back in real time can be provided 

[0197] Since the data extractor also extracts plural I pictures from MPEG data having plural t pictures at irrten^als cor- 
responding to the measurement result of the load measuring unit, the MPEG data able to be played back in real time 
can be provided. 
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[01 98] The device of the invention is also provided with the encxxler for encoding image signals from the video camera 
in real time and generating video data having plural frame data and the buffer for ten^rarily storing the video data gen- 
erated by the encoder. In the data extractor, by thinning frame data among plural frame data in the video data stored in 
the buffer, the number of frame data based on the measurement result of the load measuring unit is extracted from the 
5 video data. Therefore, the display quality of the video data is prevented from being deteriorated, while the network load 
is alleviated. 

[0199] Furthermore, the video data distribution system of the Invention is provided with the video data distribution 
device which comprises the load measuring unit for measuring the load condition of the video data distribution system, 
the data extractor for extracting the number of frame data corresponding to the measurement result of the load meas- 
10 uring unit from video data Indudi ng plural frame data and the transmitter for transmitting the frame data extracted by the 
data extractor via the network, and the video data playback device for receiving the frame data transmitted from the 
transmitter of the video data distributkm device via the network and playing back the received frame data. Therefore, 
the video data can be played back in real time. 

[0200] Furthermore, since the load measuring unit measures the k)ad of the processor for controlling operation of the 
IS video data playback device, transmission of unused frame data is inhibited, and the transmitted amount of the video 
data can be reduced. 

[0201] Moreover, plural video data playback devices are connected to the network, and one frame data transmitted 
from the transmitter of the vkieo data distribution device onto the network is received by each of the plural video data 
playback devices. Therefbre, the video data can be transmitted to plural video data playt)ack devices once, and the net- 

20 work load can be tightened. 

[0202] The vkleo data playback device also transmits the data transfer request in which data amount is designated to 
the video data distribution device plural times, and upon receiving the data transfer request, the video data distribution 
device transmits frame data based on the data size designated by the data transfer request Therefore, the video data 
can be played back in real time based on the instruction of the video data playt>ack device. 

25 [0203] The video data playback device further transmits the data transfer request In which video data is designated, 
and upon receiving the data transfer request, the vkjeo data distrbutk)n device transmits plural packets having a part 
of frame data of the video data at predetermined intervals. Therefore, the video data can be played back in real time. 
[0204] The vWeo data distribution method of the invention comprises the transmission level determining step of deter- 
mining the transmission level in accordarwe with the load on the video data distribution system, the data extracting step 

30 of extracting the number of frame data con-esponding to the transmisswn level determined in the transmission level 
determining step from video data including plural frame data and the transmitting step of transmitting the frame data 
extracted in the data extracting step. Therefore, the video data can be played back in real tima 
[0205] Furthermore, the transmission level determining step is performed in the video data playback device, and is 
provided with the load measuring step of measuring the load of the processor for controlling operation of the video data 

35 playback device, the determining step of determining the transmission level in accordance with the measurement result 
of the load measuring step and the transmission level transmitting step of transmitting the transmission level determined 
by the determining step from the vWeo data playback device to the video data distribution device. Therefore, the video 
data can be played back in real time. 

[0206] Furthermore, since the playback step is provided in which the video data playback device receives the frame 
40 data transmitted in the transnrtitting step and plays back the received frame data, the video data can be played back in 
real time. 

[0207] Moreover, in the transmission level determining step, when the vkleo data playback device qukMy fbnwards 
and plays back the video data, the transmission level is determined in such a manner that the video data with a part of 
the frame data thinned from plural frame data included in the video data is extracted. When the quick fbnvarding play- 
45 back is not performed, the transmission level is determined in such a manner that the frame data of the vkleo data is 
not thinned. Therefore, the network toad can further be reduced. 

[0208] Additionally, in the data extracting step, when the video data playback device quicWy fomvards and plays back 
the video data including plural frame data and voice data, the voice data is deleted from the video data and the number 
of frame data corresponding to the transmission level is extracted to generate video data. In the transmitting step, the 
so vkieo data generated in the data extracting step is transmitted. Therefore, the network load can further be reduced. 

INDUSTRIAL APPLICABILITY 

[0209] As aforementioned, the video data distrilxJtion device, the video data distribution system and the video data 
55 distribution method of the invention are suitable for use. for example, in a vkleo data distrSsution system for distributing 
a large amount of video data. 
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Claims 

1 . A video data distribution device which conprises: 

5 a load measuring unit for measuring a load condition of a network or the video data distrltsution device; 

a data e)(tractor for extracting the number of frame data corresponding to a measurement result of said load 

measuring unit from video data including plural frame data; and 

a transmitter for transmitting the frame data extracted by the data extractor. 

10 2. The video data distribution device according to claim 1 wherein based on the measurement result of the load meas- 
uring unit, the data extractor extracts all the frame data of the video data when the load is low. and extracts a part 
of the frame data of said video data when the load is high. 

3. The video data distribution device accoiding to claim 1 wherein the data extractor extracts the number of frame data 
75 by thinning frame data, based on the measurement result of the load measuring unit, among the plural frame data. 

4. The video data distribution device according to claim 1 wherein the data extractor extracts the video data with inter- 
frame conpressed frame data deleted therefrom from the video data having intra-frame compressed frame data 
and inter-frame compressed frame data based on the measurement result of the load measuring unit, and 

20 

the transmitter transmits the video data extracted by the data extractor. 

5. The video data distribution device according to claim 1 wherein the video data is MPEG data. 

25 6. The video data distribution device according to claim 5 wherein the data extractor generates the MPEG data with 
P picture deleted therefrom from MPEG data having I plctwe and P picture in accordance with the measurement 
result of the load measuring unit. 

7. The video data distribution device according to claim 5 wherein the data extractor generates MPEG data with B pio- 
30 ture deleted therefrom from MPEG data having I picture and B picture in accordance with the measurement result 

of the load measuring unit. 

8. The video data distribution device according to claim 5 wherein the data extractor generates MPEG data with P pic- 
ture and B picture deleted therefrom from MPEG data having I picture. P picture and B picture in accordance with 

35 the measurement result of the load measuring unit. 

9. The video data distribution device according to claim 5 wherein the data extractor extracts plural I pictures from 
MPEG data having plural I pictures at inten^als corresponding to the measurement result of the load measuring 
unit. 

40 

10. The video data distribution device according to claim 1 which comprises: 

an encoder for encoding image signals from a video camera in real time and generating video data having plu- 
ral frame data; and 

45 a buffer for temporarily storing the video data generated by the encoder, wherein 

by thinning frame data among plural frame data in the video data stored in said buffer, the data extractor 
extracts the number of frame data based on the measurement result of the load measuring unit from said video 
data. 

so 11. A video data distribution system which comprises: 

a video data distribution device comprising a load, measuring unit for measuring a load condition of the video 
data distribution system, a data extractor for extracting the number of fi'ame data caresponding to a measure- 
ment result of said load measuring unit from video data including plural frame data and a transmitter for trans- 
55 mitting the frame data extracted by the data extractor via a network; and 

a video data playback device for receiving the frame data transmitted from the transmitter of said video data 
distribution device via said network and playing back the received frame data. 
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12. The video data distribution system according to claim 11 wherein the load measuring unit measures a load of a 
processor for conlrolling operation of the video data playback device. 

13. The video data distribution system according to claim 1 2 wherein plural video data playback devices are connected 
5 to the network, and 

one frame data transmitted from the transmitter of the video data distribution device onto said network is 
received by each of said plural video data playt}ack devices. 

10 14. The video data distribution system according to claim 11 wherein the video data playback device transmits a data 
transfer request in which data amount is designated to the video data distribution device plural times, and 

upon receiving said data transfer request plural times, the video data distribution device transmits frame data 
based on the data amount designated by each data transfer request for said each data transfer request 

15 

15. The video data distribution system according to claim 12 wherein the video data playback device transmits a data 
transfer request in which video data is designated, and 

upon receiving said data transfer request, the video data distribution device transmits plural packets having a 
20 part of frame data of said video data at predetermined intervals. 

16. A video data distribution method which comprises: 

a transmission level determining step of determining a transmission level In accordance with a load of a video 
25 data distribution system; 

a data extracting step of extracting the number of frame data corresponding to the transmission level deter- 
mined by said transmission level determining step from video data including plural frame data; and 
a transmitting step of transmitting the frame data extracted by said data extracting step. 

30 17. The video data distribution method according to dairn 16 wherein the transmission level determining step is per- 
formed in a video data playback device, and comprises 

(a) a load measuring step of measuring a load of a processor for controlling operation of the video data play- 
back device. 

35 (b) a determining step of determining a transmission level in accordance with a measurement result of the load 

measuring step, and 

(c) a transmission level transmitting step of transmitting the transmission level determined by the determining 
step from the video data playback device to the video data distribution device. 

40 18. The video data distribution method according to claim 1S which comprises a playback step in which the video data 
playback device receives the frame data transmitted by the transmitting step and plays back the received frame 
data. 

19. The video data distribution method according to claim 16 wherein in the transmission level determining step^ when 
45 the video data playback device plays back the video data with fast speed, the transmission level is determined in 
such a manner that the video data with a part of frame data thinned from plural frame data included in the vkieo 
data is extracted, and when fast playback is not performed, the transmission level is determined in such a manner 
that the frame data of the video data is not thinned. 

so 20. The video data distribution method according to daim 16 v)/herein in the data extracting step, when the video data 
ptayl>ack device quickly fonA/ards and plays back the video data induding plural frame data and voice data, said 
voice data is deleted from the video data and the number of frame data con-esponding to the transmission level is 
extracted to generate video data, and 

55 in the transmitting step, the video data generated by said data extracting step is transmitted. 
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